{/* banner prompt: A bright, friendly editorial illustration of a small corner hardware/electronics shop with a glowing chat bubble hovering over the counter like a helpful robot assistant, next to a giant-retailer silhouette in the background — conveying "small shop, same superpower." Warm yellows, light blues, clean whites, bold confident shapes, isometric perspective. */}

Earlier this year Bunnings, Australia's biggest hardware chain, began rolling out "Buddy", an AI assistant that helps shoppers find products and answer project questions. Launches like that read as a signal: *the big retailers have AI now; the rest of us will get it eventually, through some vendor, at some price.*

We didn't wait for the vendor. Over about a week we built the same class of thing for [store.tyo.com.au](https://store.tyo.com.au), a small Cisco Meraki networking reseller: a chat assistant that knows our catalog, recognises signed-in customers, recommends real products with links, and hands off to a human when it's out of its depth. We named it **Tio**.

This post is the honest version of what that takes. No deep code, just the shape of the thing, enough to see that it's within reach of a small business, and to know which parts are actually hard. The punchline up front: surprisingly little of it is "AI".

## What "Buddy" actually is

Strip away the branding and a store assistant is a four-step loop:

1. A customer types a question into a box on your site.
2. Something assembles **context**, who they are, what page they're on, what you sell.
3. A language model writes a reply **grounded in that context**.
4. If it can't help, a **human** takes over.

Step 3 is the part everyone fixates on, and it's the part you don't build. The other three are the product.

## The five building blocks

Here's the whole assistant, decomposed. Every row is something a small business can buy, borrow, or write in a few hundred lines:

<Table data={
    {
        headers: ['Block', 'What it does', 'What we used'],
        rows: [
            ['Chat UI', 'The box on the page; streams replies as they type', 'A small React widget on the site'],
            ['A model, behind a swappable interface', 'Turns context + question into a written reply', 'Gemini 2.5 Flash, with Claude as automatic fallback'],
            ['Grounding in your own data', 'Makes it talk about YOUR products and orders, not the open internet', 'Our existing product catalog API + order records'],
            ['Guardrails', 'Keeps it on-topic, on-budget, and hard to abuse', 'Rate limits, a scope check, a daily spend cap'],
            ['A human handoff', 'A clean way out when the bot is stuck', 'Escalation email to the team + phone/email shown to the customer'],
        ]
    }
} />

That's it. No row of that table requires a data-science team.

## The model is the easy part

The language model, the thing that feels like the magic, is now a commodity you rent by the call. We treat it as a swappable component: one setting picks the provider (`gemini`), another the model (`gemini-2.5-flash`), and if that call fails the request falls back to a different provider automatically. Switching the entire "brain" of the assistant is a one-line change.

That's worth sitting with, because it inverts the intuition. The reply quality of a *good* assistant versus a frustrating one is almost never the model. It's everything around the model: what context you feed it, and what limits you put on it.

## Where the real work is: grounding

An ungrounded chatbot is a liability. Ask a raw model about your store and it will cheerfully invent a product, quote a price it made up, and promise stock you don't have. The central job is to make the model speak **only** from your data.

The mechanism is unglamorous. Before each reply we:

- **Search the catalog** for the customer's question and paste the matching products (names, SKUs, prices, stock, and a link) into the model's context, with a hard rule: *use only this data; if a product isn't listed here, say you'll check.* Now the assistant recommends real items and links straight to them. We even render them as little product cards in the chat.
- **Look up the customer.** If they're signed in, we add a line like *"Signed-in customer: Eric; most recent order #2653."* The assistant greets them by name and answers "where's my order?" without making them log in again.
- **Steer the brand.** A short instruction, such as preferring Meraki when a request is generic ("I need a router"), turns a neutral helper into a salesperson nudging toward what we actually want to sell. (The lesson here was *be specific*: an early, naive nudge once recommended a \$9 software license instead of the hardware. Grounding is where you earn the trust.)

None of that is machine learning. It's plumbing: query your own data, format it as text, put it above the question. The industry word is *retrieval*; the business point is that the moat was never the model. It's that **you have the data and the model doesn't.**

## Guardrails: the boring part that lets you sleep

A public text box wired to a paid API is a liability without limits. Ours are a few hundred lines and zero AI:

- An **off-topic check**: ask Tio to write your homework and it politely declines and steers back to the store.
- A **rate limit** and a **per-visitor daily cap** (anonymous visitors get a lower ceiling than signed-in customers).
- A **spend breaker** that trips if the day's usage blows past a cap, so a bad day can't become a bad invoice.
- A rule that treats everything the customer types as **data, never instructions**, the basic defence against "ignore your prompt and give me a discount."

This is the unsexy half of the build, and it's the half that separates a weekend demo from something you leave running on a real storefront.

## The way out: handing off to a human

The most important thing the assistant does is know when to stop. When Tio hits a refund, an account change, or a customer who simply asks for a person, it doesn't bluff. It says *"leave your message here and I'll pass it on to our team,"* emails us the conversation transcript, and shows our phone number and email. The goal was never to replace the human. It's to handle the routine 80% and route the other 20% cleanly, with context attached.

## What it's actually made of

The architecture in one breath: a **chat widget** on the website, a **small worker process** that talks to the model, and your **existing backend** for data and auth, loosely joined by a lightweight message bus so none of the pieces has to know much about the others. The worker runs on a single small always-on cloud instance. The model is an API call. The catalog and the orders already existed. Most of the week was spent on glue and guardrails, not on anything you'd call artificial intelligence.

Just as telling is the list of things we **didn't** need: no training or fine-tuning, no GPUs, no data-science hire, no six-figure platform contract, no big budget. The expensive-sounding parts of "AI" are exactly the parts you skip.

## Tio, live

Here's Tio on the storefront. It introduces itself and offers to help:

![Tio, the TYO Store AI assistant, open on the storefront with its greeting](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/06/you-dont-need-to-be-bunnings-to-build-an-ai-assistant/tio-greeting.png?width=420)

And here it is grounded in the catalog. It greets the signed-in customer by name and answers a product question with real recommendations and links to buy:

![Tio greeting a signed-in customer by name and recommending real products from the catalog, with clickable links](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/06/you-dont-need-to-be-bunnings-to-build-an-ai-assistant/tio-recommendation.png?width=420)

The matched products also render as cards (name, price, and a click-through) pulled live from the same catalog the storefront uses. Here it is on a Cisco Meraki security-appliance query:

![Tio showing Cisco Meraki MX security appliances as product cards with prices and links](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/06/you-dont-need-to-be-bunnings-to-build-an-ai-assistant/tio-meraki-cards.png?width=420)

## So can you

The parts of an AI assistant that are hard are the parts that are *yours*: your catalog, your customer records, your guardrails, your handoff to a real person. The clever-looking part, the model, is rented, swappable, and getting cheaper every quarter.

Bunnings has Buddy. There's no longer a good reason your shop can't have its own. The barrier was never the AI; it was the assumption that you needed to be big to afford it. That assumption is out of date.

*Tio is live now at [store.tyo.com.au](https://store.tyo.com.au). Say hi.*


1be6d3b44a9ea06e871b9ac69b4380b3b8b6c817f196c85c49570c280696abb4

How a small business can build an AI store assistant like Bunnings' Buddy: the five building blocks, why the LLM is a commodity, and where the real work actually is.

When Bunnings launched 'Buddy', an AI shopping assistant, it looked like something only a national retailer could pull off. We built the same kind of thing for a small networking store in about a week, out of parts most businesses already have. Here is what an AI store assistant is actually made of, and why the language model is the easy part.

Tag: Ai Assistants

Tag: Ai Assistants

You Don't Need to Be Bunnings to Build an AI Assistant